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NETWORK STRUCTURES FOR DISTRIBUTED SYSTEMS 


Distributed systems, as we use the term, will make extensive use 
of data communications. Last month we considered how appli- 
cation systems might be partitioned and distributed, based on the 
natural clustering of activities. In this report, we consider the 
structure of the data communications network for tying the parti- 
tions together. The trend today is toward network structures and 
protocols (control procedures) that are largely independent of 
specific applications and specific equipment. But even within this 
trend, there are several major schools of thought—private versus 
public networks and centralized versus distributed control, to 
name a few. Here is an overview of what is emerging in data com- 


munications networks. 


M ontgomery Ward, with headquarters in Chi- 
cago, Illinois, is the huge retail department store 
and catalog sales office arm of Marcor, Inc. Total 
corporate sales are over $4.6 billion annually, the 
bulk of which are Montgomery Ward sales. The 
corporation employs some 125,000 people. 

Montgomery Ward's data processing has been 
regionalized, with processing centers in Chicago, 
Illinois; Baltimore, Maryland; Kansas City, Kan- 
sas; and Oakland, California. IBM 370 equipment 
is used in these four centers. In addition, the com- 
pany has been using a variety of terminal types in 
its stores and catalog sales offices. These terminal 
types have included IBM 3270 CRT-type termi- 
nals, IBM System 3 remote job entry terminals, 
NCR 280 point of sale terminals, TRW credit 
authorization pads, and Teletypes. 

But the variations did not end with the types of 
terminals; different communication line speeds 
and disciplines have been necessary. On the 
leased line network, these speeds included 1200 


bits per second asynchronous operation, and 
2400, 4800, and 7200 bps synchronous operation. 
In addition, the Teletypes have been operated 
over the dial network at 110 bps asynchronous. 
The resulting network included a large number 
of lines, operating at different speeds and under 
different disciplines, for serving the variety of ap- 
plications. The amount of line sharing that could 


-be done among applications was quite limited. 


Moreover, transaction activity is growing. By 
1978, Montgomery Ward expects to need a total 
of about 20,000 terminals in its stores and catalog 
sales offices. Operating costs have been growing 
right along with this transaction growth. 

So, in 1974, Montgomery Ward decided to look 
at alternative solutions to the data commu- 
nications problem. In 1975, they became inter- 
ested in what NCR had to offer. NCR had 
developed their 721 communications processor 
and supporting software, and were in the process _ 
of formulating their Data Communications Util- 
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ity (DCU) approach to data communications. 
Montgomery Ward made significant contribu- 
tions to key concepts in pcu, such as structuring it 
as a stand-alone system. So Montgomery Ward 
placed an order for a pcu network and is now in 
the process of installing the network, with the 
first phase already in operation. 


Montgomery Ward's DCU network 


The four regional centers—at Chicago, Balti- 
more, Kansas City, and Oakland—will continue to 
perform their data processing functions as before, 
and on the IBM 370 equipment. But the 370s will 
now interface to a data communications network 
that has been supplied by NCR. Further, some of 
the terminals that will be used will be IBM-com- 
patible (in addition to other types that we will 
mention). The same network will serve all appli- 
cations. Hence the network will be largely appli- 
cation independent and computer and terminal 
independent. 

Here is a summary of the network con- 
figuration that Montgomery Ward has chosen. 
The network components, of course, can be con- 
figured in a wide variety of ways so that this con- 
figuration is just one example of what is possible. 

Hardware configuration. A dual front end proc- 
essor is being installed at each of the four regional 
centers; dual processors are being used for 
backup. This is the NCR 721 communications 
processor, operating under the transaction ori- 
ented executive operating system. Each of these 
regional front ends is tied to three remote com- 
munications processors (RcpPs), which are 
also NCR 721s. In a later phase of the system, 
the four front ends will be tied together, al- 
lowing in theory any-terminal-to-any-terminal 
communication. 

The NCR 721 is a mini-computer with a special 
hardware multiplexor for data communications 
use. The multiplexor handles all input, output, 
and communications checking. It stores charac- 
ters directly into processor memory, interrupting 
the processor only after the complete message is 
assembled in memory. The processor is thus avail- 
able for performing a large number of network 
management functions, to be discussed. 

Connected to each rcp by a common trunk, 
and adjacent to it, is an NCR 725 distributed 
processor. This uses the same mini as the 721 but 
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does not include the multiplexor. The 725 is used 
for capturing and storing transactions and routine 
credit authorization messages during the day, for 
transmission at night to the parent regional cen- 
ter. The 725 has a printer, card reader, and mag- 
netic tape unit attached and functions as a remote 
entry station to a host computer. 

The rcp also interfaces with a variety of termi- 
nals at the store or catalog office level. 

At each store location is one or more concen- 
trators for serving terminals in the store. Each 
concentrator is connected via the network to its 
parent rcp. One common type of concentrator 
handles a cluster of NCR 280 point of sale termi- 
nals and ksr Teletype compatible terminals in the 
catalog sales department. Another handles TRW 
credit authorization pads, used with older style 
cash registers. If the parent rcp is down or the 
communications line fails, the concentrator stores 
point of sale transactions on cassettes until the 
failure is corrected. 

The rcp also interfaces two other types of 
units. One is a control unit for NCR 7300 crr ter- 
minals, which are IBM 3270 compatible. The 
other is the ability of the rcp to dial up an asr 
Teletype terminal at a catalog sales office and 
request the transmission of transactions that have 
been recorded on paper tape. 

In the first installation phase, the pcu is being 
used for handling the types of message flow to be 
discussed shortly. The whole network has been 
brought under pcu management. Message. 
switching, which was one of Montgomery Ward’s 
original goals for the network, has been scheduled 
for later implementation, as have the restart 
capabilities. 

Network control. There is no overall central 
point of control in a pcu network. Each node has 
the information it needs about the status of adja- 
cent nodes and communications links. NCR cur- 
rently offers over 30 software modules for use in 
the 721 by which networks can be configured as 
the user desires. These modules reside in the 
front end processors and remote communications 
processors. 

The functions performed by network control 
include routing, alternate routing, acknowledge- 
ment, logging, packet formation, load smoothing, 
and restart. An end-to-end acknowledgement 
feature, optional by message, is provided. Each 
packet header contains a disposition code, to in- 


dicate what should be done if the packet cannot 
be delivered. 

Data transmission. Messages are transmitted in 
packet form. Packets are variable in length up to 
a maximum of 255 characters. Transmission 
speeds from terminals to Rcps generally will be 
between 300 and 1800 bps asynchronous and 
4800 and 7200 bps synchronous. From rcp to the 
front end, speeds generally will be 9600 bps, al- 
though 56 kbps is being considered. Montgomery 
Ward has chosen to use multiple 9600 bps lines 
over dispersed paths, for load sharing and backup. 
Geographically dispersed paths are being used to 
reduce the chance of both lines being down at the 
same time. 

Message flow. During store business hours, the 
network is being used for credit authorization 
queries and responses, for credit referral queries 
and responses, and for some on-line file mainte- 
nance functions. For instance, when a customer 
wishes to purchase something on credit, the sales 
clerk enters the account number and amount on 
the NCR 280 pos terminal (or on the TRW pad, if 
a manual register is being used). The message goes 
through the store’s concentrator, onto the net- 
work, to the rcp. The rcp can be hundreds of 
miles away. The rcp recognizes the message as a 
credit query and routes it to the parent front end 
processor—which in turn directs it to the TRW 
4000/IBM 370 processor. If credit is satisfactory, 
a message to that effect is sent back along the 
same route and the sales transaction is completed. 
If there is a question about the customer’s credit, 
a refer signal is given. The clerk then calls the 
credit office on the telephone, describes the trans- 
action, and gives the account number. A credit 
authorizer, operating an NCR 7300 crt-type ter- 
minal, enters a credit referral query. This goes up 
through the network to the regional center. The 
response is a multi-line message of the customer’s 
name, address, buying and payment history. After 
looking at it, the credit authorizer may authorize 
the sale then and there. Or the credit authorizer 
may want to talk to the customer on the phone, 
to get additional information, before making a 
decision. 

If the credit card has been reported stolen or 
for comparable reasons, the system notifies the 
sales clerk. The sales clerk keeps the card and 
calls the appropriate member of management. 

When a credit sale has been authorized, or any 
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other type of sale consumated, the message flows 
to the rcp where it is recognized as a sale trans- 
action. The rcp directs the message to the 725 
distributed processor. The 725 records it on mag- 
netic tape, for transmission that night to the re- 
gional center. 

What the network does for Montgomery Ward. 
This discussion has touched only on the highlights 
of the data communications network, but several 
points should be apparent. The same network is 
being used to serve all applications. A variety of 
terminal types are being accommodated. If 
Montgomery Ward wants to add a new terminal 
type or a new application, chances are good that 
these can be added with little concern for network 
characteristics. The data communications func- 
tions have been separated from the data process- 
ing functions. The main CPUs are not involved 
with data communications functions. And the net- 
work is quite robust. Alternate routings are avail- 
able. Moreover, there is no central network 
control processor which, if it goes down, shuts 
down the network. 

So Montgomery Ward is well along in the in- 
stallation of a new generation of data communi- 
cations networks. 


Aspects of data communications networks 


The subject of data communications networks 
is huge. In a report such as this, it is possible to 
touch on only a few aspects of networks. To give 
an idea of the scope of the subject, the following 
are some of the high level aspects that could be 
used to categorize networks. 


ASPECTS OF NETWORKS 


1. Ownership: public, private, shared private. 

2. Structure: point-to-point, multi-point (party line), cen- 
tralized (star), multi-star, hierarchy (tree), ring, or dis- 
tributed (peer, with all processors of equal rank) network. 

3. Protocols (control procedures) 

a) Inter-element: between user and host, user and termi- 
nal, host and host, host and terminal, host and node, 
node and node, node and terminal. 

b) Type of traffic: one-way messages (packets for fast 
transmission, store-and-forward for throughput), two- 
way messages (interactive), data transfer, process (job) 
transfer. 

c) Switching: circuit, virtual circuit, message, packet. 

d) Routing: dynamic, preferred, fixed. 

4, Standards 
a) Interfaces: between host and node, terminal and node, 

and between one network and another. 

b) Canonical elements: virtual terminal, virtual host. 


5. Controls: network command language, error control, 
routing control, load control. 
6. Transmission media: cable, microwave, satellite. 
7. Transmission: analog, digital. 
8. Performance characteristics: integrity, reliability, recov- 
ery, security, throughput, response time. 
9. Network evaluation: modelling, vulnerability analysis, 
growth analysis. 
10. User aspects: user identification, user assistance, usage ac- 
counting and billing. 
1]. Legal and regulatory considerations. 


It is clearly impractical to try to cover even the 
major alternatives from among the many com- 
binations of the above aspects. So, in this report, 
we will concentrate mainly on private data com- 
munications networks, for reasons that we will 
give below. But to set the stage for discussing 
what is happening with private networks, it will 
help to briefly review how computer networks— 
both public and private—have emerged. 


Evolution of data communications networks 


This material has been drawn from McFadyen 
and Thomas (Reference 1) Davies (Reference 3), 
Blanc and Cotton (References 4a and 4b), Frisch 
and Frank (Reference 5a), and Sanders (Refer- 
ences 3 and 13 plus an interview). 

McFadyen and Thomas trace the development 
of private data communications networks. In the 
earliest days of computers, each application pro- 
gram had its own input-output routines for com- 
municating with peripheral devices. The next 
step was to develop generalized input-output 
control software for all locally attached devices, 
via batch-type communications. The next exten- 
sion was for the generalized I/O software to serve 
remote terminals, as well as local peripherals. 
Then came teleprocessing control systems, which 
were specific as to device type and line speed. 
The last stage before the present generation was 
tree-structured networks with node tele- 
processing control; however, it still required spe- 
cialized control routines for specific devices. 
Moreover, throughout all of this development, 
these specialized control routines for devices 
were embedded in the application programs. So 
there was tight coupling between the application 
programs and the data communications network. 

We are just witnessing the arrival of the dis- 
tributed, device-independent private network. 
These include IBM’s Systems Network Archi- 
tecture (sna), NCR’s pcu, Digital Equipment 
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Corporation’s DEcNET, Computer Transmission 
Corporation’s Pacult, and others. While these of- 
ferings have quite similar objectives, they have 
quite different structures, as we will discuss 
shortly. 

Somewhat in parallel with these developments, 
large semi-private and public networks were 
being developed by telecommunications agencies 
and quasi-public bodies in a number of countries. 
Mr. R. W. Sanders, President of Computer Trans- 
mission Corporation, reviewed these devel- 
opments for us. Among the first of modern 
packet-type networks was the Sita network, de- 
veloped in the mid-1960s for joint use by inter- 
national airlines; we discussed the Sita network 
in our February 1975 issue. This was followed 
shortly by the Arpa Net (discussed in our Novem- 
ber 1971 and January 1973 reports), which has 
tied together universities and research centers 
across the U.S. and in the United Kingdom. The 
ArpA Net has had a very significant influence on 
network development. TyMNeEtT, developed by 
Tymshare, Inc., originally was set up to serve the 
company’s time sharing customers, but soon ex- 
panded into a value-added type of operation 
through joint use agreements (as we discussed in 
January 1973). The crne network in Spain be- 
came operational in 1972. The Telenet Commu- 
nications Corporation began offering public 
packet switched communications services in the 
U.S. in 1975, as a common carrier. In the U.K., the 
EPss network is well along toward operational 
status, as is the Datapac network in Canada and 
the CycLaDEs and Transpac network in France. | 
(We discussed the Telenet, CTNE, EPss, Datapac, 
and CycLabDEs networks in our February 1975 is- 
sue and expect to describe the TRANsPac network 
in the not-distant future.) 

Computer Transmission Corporation (TRAN), 
of El Segundo, California, was active throughout 
most of this period. They questioned the effec- 
tiveness of some of the goals in the “pure” packet 
switched networks—goals such as dynamic rout- 
ing and virtual terminals. What Tran has devel- 
oped is a hybrid system that they call Pacurt, for 
a combination of packet and circuit switching. 
We will have more to say about Pacuir later in 
this report. It is interesting to note that TRAN has 
supplied switching equipment for Canada’s Data- 
route network (the first phase of Canada’s total 
digital network), and is supplying the switching — 


equipment to Pacific Telephone for the State of 
California’s new data communications network. 

Sanders reviewed for us the goals of much of 
the early development work in networks. These 
were: 


GOALS IN NETWORK DEVELOPMENT 


]. A universal network access arrangement—by using the 
concepts of “virtual terminal” and “virtual host,” design- 
ers hoped to be able to connect just about any terminal 
and any host computer to the network; within the net- 
work, everything would be handled in a standard (virtual) 
manner. 

2. Independence from any particular supplier, of computers 
or of terminals. 

3. Highly effective error control in an environment of noise 
and disruption of communications services, by means of 
automatic error detection, retransmission, and the use of 
alternate routes. 

4. More effective use of communication bandwidths by the 
concentration of many “virtual circuits” on high-speed 
inter-node trunk circuits. 

5. Accessing multiple terminals without the use of polling, 
since polling is a wasteful operation. 

6. Controlling the flow of traffic into the network and 
through the network, so that storage facilities do not be- 
come overloaded and message queues too long—or worse, 
messages lost. 


Two other aspects were mentioned to us by 
William Helgeson of Honeywell Information Sys- 
tems. One has been the emphasis on fast response 
time, rather than thoughput (as was characteristic 
of store-and-forward systems). The other aspect 
was the emphasis on end-to-end control of trans- 
mission and communications, in addition to 
point-to-point control. 

It is evident from this list that the designers 
were seeking complete data communications 
services, not just data transmission services. 
Packet switching was seen as a way of accom- 
plishing these goals, as contrasted with circuit 
switching or conventional message switching. For 
instance, the concepts of virtual terminals and 
virtual hosts probably could not be implemented 
in a regular circuit switching environment. 

The point here is important, so perhaps we had 
better reiterate it. The telecommunication 
agencies witnessed the development of private 
data communications networks in which they 
provided only the data transmission services. But 
telecommunication agencies generally feel that 
private networks are wasteful; customers can be 
served more effectively by public networks. 
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Packet switched public networks were seen as a 
way by which the telecommunication agencies 
could offer complete data communications 
services. 

But this goal leads to further complexities. De- 
sign standards are needed, so that the public 
(packet switched) networks of one country will 
interface properly with those of other countries— 
just the way that the dial telephone networks in- 
terface. So some type of common structure was 
and is needed. Is this an impossible dream? 

Surprisingly, it is not out of the realm of possi- 
bility. In October 1975, the French prt, the Cana- 
dian Trans Canada Telephone System, and 
Telenet in the U.S. offered a proposal to CcitrT for 
a standard structure. This was an informal pro- 
posal because, for one thing, Telenet cannot speak 
for all telecommunieations agencies in the U.S. 
(Ccitt is the standards organization of the na- 
tional telecommunication agencies and tele- 
communication equipment manufacturers.) The 
proposal was very well received, we were told, 
and a formal proposal to the same ends was sub- 
mitted later in 1975 by the French ptr and the 
U.K. Post Office. The proposal, code named X-25, 
was approved in March of this year by the respon- 
sible CcirT study group. We understand that ap- 
proval by the Ccirtr plenary session in September 
seems assured—in which case, X-25 will become 
an international standard. So we might just see a 
common structure for public data commu- 


nications services adopted in the not-distant fu- 


ture. But it may take a number of years for such 
services to be implemented in any particular 
country. 

While public data communications networks 
are important and might become the mechanism 
for data communications by, say, 1990, we see 
private networks as playing a dominant role 
for at least the next five to ten years. Tele- 
communication agencies will offer more and bet- 
ter data transmission services, such as the Bell 
System’s pps and Canada’s Dataroute. Some will 
be offering packet switched services, such as Tele- 
net, Datapac, TRANSpPAC, and Epss, but probably 
users will use these as data transmission services at 
the outset. The reason users will do so is that they 
often will have to couple such services with more 
conventional data transmission services; the 
packet switched services will not be available, 
end-to-end, to all remote user locations. 


This, then, is why we will be concentrating on 
developments in private data communications 
networks in this report. We see them as providing 
the bulk of data communication services for at 
least the next five to ten years. But public net- 
works are coming, and users would be wise, we 
think, to take advantage of them at least as data 
transmission services as they become available. 

Let us now consider the structure of some of 
the leading private network offerings. 


Variations in network structure 


The Montgomery Ward network, described 
earlier in this report, is an example of a private 
network—for the private use of the company. The 
hardware/software complexes for switching mes- 
sages, performing error control, and so on were 
obtained in this instance from NCR. The trans- 
mission services are obtained from the common 
carriers. 

We will give a summary of several offerings in 
overall network structure, following which we 
will describe some line control protocols. 


IBM's SNA 


IBM’s Systems Network Architecture is a cen- 
trally controlled, distributed intelligence network 
structure. It provides a common structure for a 
data communications network in much the same 
way that the IBM 360/370 has provided a com- 
mon structure for data processing. 

There are four levels of intelligence in sna, but 
the user need not use all four levels. The top level 
is the Virtual Telecommunications Access 
Method (vTam), located in the main CPU, which 
provides overall control for the whole network. 
(Optionally, this function can be performed by 
TCAM.) At the next level is the Network Control 
Program (Ncp), which provides local network 
management under the direction of vram. The 
NncP resides in the front end processors and inter- 
mediate node processors (currently IBM 3704 or 
3705). The next level is the cluster control level— 
the terminal control level. The fourth level is the 
terminal level, should intelligent terminals be 
used. | 

SNA uses Synchronous Data Link Control 
(SDLC) as the line control protocol. We will discuss 
spc shortly. As will be pointed out, spuc is not 
compatible with IBM’s previous offerings such as 
the binary synchronous line protocol (Bsc). 
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With programmable control units in the net- 
work, device control functions are moved out of 
the host cpu into the network controllers. The 
structure of sna determines which network func- 
tions can be located in which processors, in order 
to achieve compatibility throughout the network 
and among the various applications. Thus, the 
functions to be performed at each level of the net- 
work are precisely defined. 

User programs need not be concerned with the 
physical makeup of the network nor with specific 
transmission services. The user program simply 
provides the data to be transmitted and calls for 
the desired service by name. The network has the 
responsibility of getting the data to the desired 
destination. 

As is true of this generation of network man- 
agement systems, SNA requires an appreciable 
overhead as compared with, say, a point-to-point 
communication system for one application. The 
rationale for something like sna is when an organ- 
ization is using a variety of terminal types, oper- 


ating at different speeds and under different 


disciplines, for a variety of applications. 

It should be noted that not only are some net- 
work functions moved out of the cpu into the net- 
work processors but also some application logic 
can be similarly moved. For instance, selected 
data can be stored at the local level for answering 
most queries and validating most input. Only in 
exceptional cases need reference be made to the 
central master files or data base. However, top 
level network control still resides in the host crv. 


NCR‘’s DCU 


We discussed a number of the characteristics of 
the pcu structure earlier in this issue, in con- 
nection with the Montgomery Ward network. We 
will try not to repeat too much. 

Dcv is a distributed control, distributed in- 
telligence network structure. The structure has 
three potential levels of intelligence, not all of 
which need be used. The top level is the node 
processor, the NCR 721, operating under the Tox 
operating system (Transaction Oriented Execu- 
tive). This node processor operates either as a 
front end for a host computer or as the network 
management processor at a remote node of the 
network. Control is distributed; there is no proc- 
essor that is in overall control of the network; pcu 
is stand-alone and data transparent. Should one 


node processor go down, the remainder of the 
network can continue to operate. Some appli- 
cations logic can be distributed to the node proc- 
essors, but typically a separate mini-computer 
processor will be connected to the node processor 
for handling applications-oriented functions. 

The next level is the terminal control unit level. 
The intelligence at this level typically is in the 
form of firmware. Should the parent node proc- 
essor or communications line go down, the termi- 
nal control unit stores the transactions for later 
transmission to the node processor when the fail- 
ure has been corrected. | 

The next level is the terminal level. Terminals 
may be intelligent, semi-intelligent, or non- 
intelligent. By semi-intelligent, we mean terminals 
that operate under a fixed program, such as point 
of sale devices. 

Dcvu operates under a variety of line dis- 
ciplines. These include the NCR terminal dis- 
ciplines, IBM’s ssc, Teletype, IBM 3270 I/O and 
poll inward I/O, multi-leaving, and (later this 
year) SDLC. 


DEC's DECNET 


DEcNET is a distributed control, distributed in- 
telligence network framework. It can use versions 
of the DECsystem-10, DECsystem-20, PDP-11, 
and PDP-8 computers, as well as other DEC 
products, and a variety of operating systems. In 
developing DecnetT, DEC strove to create as gen- 
eral an inter-connection mechanism as possible, 
limited only by cost and state of the technology 
considerations. 

DECNET uses a set of network protocols. One is 
the Digital Data Communications Message 
Protocol (ppcmp) which handles link traffic con- 
trol and error recovery. We will have more to say 
about ppcmp shortly. 

Another protocol is the Network Services 
Protocol (Nsp). It handles network management 
functions, routing of messages, and such. NspP uses 
a distributed philosophy. Each node is kept in- 
formed of the current state of the other nodes and 
links. 

The Data Access Protocol (DAP) allows a pro- 
gram at one node to use input-output services at 
other nodes, for using remote files and devices. 


TRAN’s PACUIT 


Computer Transmission Corporation’s Pacuir 
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is a distributed control, distributed intelligence 
network framework. As mentioned earlier, it is a 
hybrid system, making use of a combination 
of packet switching and circuit switching 
disciplines. 

Each source node in the network (a node at 
which traffic is originating) is responsible for se- 
lecting the routing for all packets originating at it. 
Thus, each node maintains the current status of 
the other nodes and links in the network. The net- 
work uses preferred routing. The preferred route 
between one node and another will always be 
used unless a line outage, high error rate, or se- 
vere traffic load requires the use of an alternate 
route. Moreover, once a route has been selected, 
it is used for all packets transmitted during that 
“virtual call’ communications session. 

PacuirT provides a data communications serv- 
ice similar to what telecommunications agencies 
will probably provide. It is a largely transparent 
packet switched service that operates under the 
virtual call discipline (which we will discuss later 
in this report). No source-to-destination protocol 
and no code conversions are performed by the 
node processors. As an example of the trans- 
parency provided, the people at TRAN say that if a 
terminal and a computer currently operate on a 
point-to-point basis, they should have no trouble 
communicating over a Pacuir network. Pacurt 
can be expanded to support the X-25 packet net- 
work access protocol of the Ccrrr. 


Line control protocols 


A good discussion of major line control proto- 
cols will be found in References 4c and 7. In addi- 
tion, Donnan and Kersey (Reference 8) give a 
good discussion for the rationale behind the spc 
protocol. 


Asynchronous protocols 


A large fraction of today’s keyboard operated 
devices operate on a character-by-character 
asynchronous basis. There is a variety of asyn- 
chronous protocols, and the characteristics of 
some are widely known. We will touch on only a 
few of the highlights of a Teletype protocol, as an 
illustration. 

The Model 35 Teletype, for instance, uses an 
11-bit frame for each character. This frame is 
made up of one start bit, 7 data bits, one parity 
bit, and two stop bits. In many instances, no par- 


ity check is performed by a receiving terminal. If 
a check is performed and an error is detected, a 
standard error character is inserted for the data 
character. Asynchronous data received by a proc- 
essor, of course, can have an error check made on 
a character-by-character basis. If an error is de- 
tected, generally all characters starting with the 
word or block in error must be retransmitted. 
Asynchronous devices can be operated on a full 
duplex or half duplex basis. 

The asynchronous protocols are important be- 
cause so many of today’s terminal devices use 
them. Networks incapable of handling asynch- 
ronous protocols will be incapable of handling 
these existing devices, and only new, compatible 
terminals will be usable. 


IBM's binary synchronous protocol 


IBM’s ssc protocol is probably the workhorse 
of today’s synchronous data transmission. By 
sending multiple characters per block, the rela- 
tive overhead is reduced as compared with 
asynchronous transmission. 

Bsc operates only in the half duplex mode. For 
each block of data transmitted, at least two line 
turnarounds are needed, of 100 to 300 millisec- 
onds each. After a block has been transmitted, the 
line direction must be turned around for sending 
the acknowledgement, and then turned around 
again for sending the next block. 

Blocks can be of variable length, and control 
characters are used to delimit the fields. Synchro- 
nism is achieved by sending at least two syn char- 
acters preceding each block. The protocol is 
character oriented and uses ascu (7 data bits plus 
parity bit), EBcpic (8 data bits) Transcode (6 data 
bits), or transparency mode. 

Bsc uses block-by-block acknowledgement for 
acknowledging either correct or incorrect 
receipt. A simple form of sequence acknowledge- 
ment is obtained by using two forms of positive 
acknowledgement—ACKO and ACK1—alter- 
nately in a series of blocks. NAK is used when a 
transmission data error is detected. 

Transparent operation for the transmission of 
text in which control character bit patterns may 
occur is obtained by the use of DLE characters be- 
fore and after the code to be sent transparently. 
If a DLE bit pattern occurs within this text, the 
system “stuffs” in an extra DLE character. The 
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receiving end recognizes two DLEs in a row, 
discards the first, and accepts the second as data. 

Bsc allows for polling and addressing on multi- 
point lines. It also includes a rigorous set of rules 
for establishing, maintaining, and terminating a 
communications session. 

Bsc could be used for asynchronous or parallel 
data transmission but IBM does not provide these 
options. 


IBM’s Synchronous Data Link Control 


IBM’s spc is one of the new generation of line 
control protocols. It is quite similar to, but not 
compatible with, two proposed standard proto- 
cols—HDLc and apccp—which we will mention 
shortly. It is an important element in IBM’s Sys- 
tems Network Architecture. Further, it is not 
compatible with ssc. 

SDLC can operate with either half duplex or full 
duplex transmission. Blocks can be of variable 
length. Each block has a fixed length header and a 
fixed length trailer section, of 24 bits each. Only 
the information field varies in length. Spuc is bit 
oriented, not character oriented, so the informa- 
tion field can be any number of bits. Were IBM to 
change to a 9-bit character, for instance, this 
could be accommodated in sDLC. 

The first field in the header is an 8-bit flag, con- 
sisting of a 0 bit, six 1 bits, and a 0 bit. This is the 
only control character used by this protocol. It is 
repeated at the end of a block and is thus used for 
providing synchronism, for identifying the begin- 
ning of a block, and for indicating the end of a 
block. The trailer portion of a block consists of a 
16-bit cyclic redundancy check and the 8-bit flag. 
The redundancy check method used is the one 
recommended by Ccirt, which will probably be- 
come an international standard. 

One of the controversial parts of spc is the 
feature that allows transmission of up to 7 blocks 
before an acknowledgement is required. The pur- 
pose is to reduce the number of line turnarounds 
in half-duplex operation. In theory, too, it would 
aid transmission by satellite; efficiency would be 
very low if the system had to wait for the ac- 
knowledgement of one block before the next 
could be transmitted. However, the seven block 
limit is too low for satellite transmission, as we 
will discuss, so it is possible that IBM will change 
this aspect of spLCc. 


An acknowledgement can be for multiple 
blocks and can be included in the header of a mes- 
sage going in the opposite direction. 

When transmission data errors are detected, 
the receiving station does nothing. When the 
sending station does not receive an acknowledge- 
ment within a specified time limit, it retransmits 
the block(s) in question. 

Each block is assigned a sequence number— 
currently 0 through 7. When the receiving end 
detects an out-of-sequence receipt, it sends a NAkK 
to the sending station. Currently, spLc requires 
that all blocks subsequent to the erroneous (or out 
of sequence) block be retransmitted but it is pos- 
sible that this feature will be changed if and when 
the number of blocks allowed before acknowl- 
edgement is increased. 

Spc has a relatively low overhead. Currently 
this is 48 bits per block, equivalent to six 8-bit 
characters. As a comparison, Bsc has an overhead 
of 64 bits per block (or eight 8-bit characters) plus 
more line turnarounds than spLc. 

For transparency, spLc uses a “bit stuffing” 
technique. The only control character used by 
SDLC is the 8-bit flag, as mentioned. Should that 
same bit pattern appear in the information field, 
it must be automatically sensed by the trans- 
mitting equipment and an extra 0 bit inserted af- 
ter the fifth 1 bit. This means that one more bit is 
added to the information field. At the receiving 
end, the equipment senses for a string of 1 bits. If 
five in a row are detected and if the next bit is a 0, 
the receiver automatically deletes it, restoring the 
information field to its original length. If the re- 
ceiver detects six 1 bits in a row, that is the flag. 

Because bit stuffing increases the number of 
bits, spLc cannot be used for asynchronous trans- 
mission or for parallel transmission. 

Spic is based on the idea of central control. 
Each link has an assigned primary station and one 
or more secondary stations. A secondary station 
can transmit to the primary only when authorized 
to do so by the primary. In addition, sptc has 
been designed to handle multi-point lines that are 
in a hub or loop arrangement. 

Spc does not perform the following functions: 
break records or messages into blocks, handle de- 
vice addressing or device status or device control, 
provide end-to-end control, establish or maintain 
or terminate a communications session, or ex- 
change supervisor signals between modems. 
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DEC’s DDCMP 


Digital Equipment Corporation’s Digital Data 
Communications Message Protocol can be used in 
either half or full duplex modes of operation. It 
has variable length blocks. The header is fixed for- 
mat and length, with its own cyclic redundancy 
check. The header is considered particularly sen- 
sitive since it controls the routing of the block; 
hence the use of its own crc. The information 
field can be of variable length. 

Dpcmp can handle synchronous, asynchronous, 
or parallel transmission. Synchronism is provided 
by the use of two ascii syn characters. The next 


_character is start of header and indicates which of 


three block types the block is. 

Docmpr is character oriented. The control char- 
acters are ascu. The information field can be any 
number of 8-bit characters. DocmpP uses the CRC- 
16 type of cyclic redundancy check, which is not 
the same as the CcirTr recommended crc. 

This protocol can transmit up to 255 blocks of 
information before an acknowledgement is re- 
quired. So blocks are assigned sequence numbers 
ranging from 2 to 255. 

When the receiving station detects a transmis- 
sion data error, it sends a NAK acknowledgement 
to the sending station, giving the block number. 
For out-of-sequence errors, no ACK or NAK is sent; 
when nothing is received within the allotted time, 
the sending station recognizes that a sequence er- 
ror has occurred. In case of either data or se- 
quence errors, all blocks subsequent to the error 
must be retransmitted. 

For transparency, a count field (of the number 
of characters in the information field) is main- 
tained in the header. Even though the informa- 
tion field may contain bit patterns that are the 
same as control characters, they are treated as 
data as long as they fall within the limits of the 
information field. 

Dpcmp can be used for point-to-point and 
multi-point operation, as well as in a hierarchical, 
ring, or network-type network. 

Other protocols. References 4c and 11 tell 
something of the status of other important proto- 
cols. The Advanced Data Communications Con- 
trol Procedures (Apccp) has been developed 
under the auspices of the American National 
Standards Institute and is being considered as a 
U.S. national standard. The High-level Data Link 


Control (HDLC) has been developed under the aus- 
pices of the International Standards Organiza- 
tion. Both of these are quite similar to spLc but 
differ from it in significant ways. The Europeans 


are taking a very active leadership role in this 


area, so it is quite possible that something like 
HDLC will win out. 

It can be seen that much activity is going on 
within the field on network architectures and 
protocols. 


The debate on network structures 


Because of all of this activity, it is not surprising 
that there are some significant differences of opin- 
ion on the structures of networks and protocols. 
We will briefly cover some of the major issues. 


Overall structure 


Farber (Reference 10) discusses the concept of 
a hierarchy of clusters, which he sees as the struc- 
ture of the future. A cluster is a group of com- 
puters, or a group of computers and one or more 
other clusters. (We discussed the concept of natu- 
ral clustering last month.) Clusters would commu- 
nicate with each other by some form of data 
communications. A cluster must have stand-alone 
capability, says Farber, in case the data commu- 
nications system is inoperative. The structure of 
the data communications within a cluster may 
vary from cluster to cluster; the same is true for 
communications among clusters. Messages can be 
sent between clusters by addressing the desired 
clusters, says Farber, and the communications 
system must insure proper delivery. 

The structure of a cluster is not fixed, as Farber 
sees it, but may be a tree, star, ring, network, or 
open bus. 

The idea of clusters ties in to the concept of 
electronic mail. This idea of electronic mail has 
proved to be very popular on the Arpa Net, we 
have been told. “Mail boxes” are assigned to users 
of the network. One user may send a message to 
another user by sending it to that other user’s mail 
box, where it is held until the other user asks the 
system for all of his mail. The process is relatively 
inexpensive and quite effective. Users find they 
use it more than the long distance telephone or 
the mails. 

Farber pointed out that messages for other 
clusters could be accumulated within a cluster. 
Then perhaps once or twice a day, a cluster would 
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forward all “mail” to the other clusters, perhaps 
using the telephone dial network. 

Hence Farber has discussed a structure that 
transcends what is normally discussed in network 
structures—namely, tree versus star versus ring 
versus network, etc. 


Blocks or packets 


In our February 1975 issue, we discussed the 
characteristics of packet switched networks. A 
packet is a block of data organized for transmis- 
sion which has both a minimum and a maximum 
length. Typically the maximum lengths have been 
set at between 1000 and 8000 bits, depending 
upon the network. A record or message that is 
longer than the network maximum must be di- 
vided into two or more packets, each with its own 
header and trailer fields. In some networks, such 
as the Arpa Net, each of these packets might fol- 
low a different path from source to destination 
through the network. 

A block (or “frame,” in spLc terminology), on 
the other hand, theoretically does not have a max- 
imum length. Like a packet, it has header and 
trailer sections. Unlike the packet, the informa- 
tion section can be of any length, limited only by 
practical considerations. In practice, very long 
records or messages might be divided into mul- 
tiple blocks—or could be treated as packets, for 
that matter. 

There is a controversy on whether network 
structures should be based on the concepts of 
packets or blocks. But Helgeson of HIS has 
pointed out that future networks should allow 
both types of service. Packets (with some max- 
imum length) would be handled by packet 
switching, for fast transmission through the net- 
work. Messages (perhaps with no theoretical max- 
imum length) would be handled by store-and- 
forward switching, for greater throughput. SpLc 
would seem to be in harmony with this viewpoint. 


Routing protocols 


Fixed routing, as the name implies, involves a 
one-only route between two stations in a net- 
work. For backup, the dial telephone network 
may be used. Fixed routing has been built into 
many of today’s private networks which use 
leased lines and (perhaps) multi-point stations. 

Circuit switching. The dial telephone network 
is probably the best example of circuit switching. 
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A user dials a desired telephone number. The net- 
work switches assign a circuit from source to des- 
tination. If the desired number is not already 
busy, it is signalled; if answered, the circuit is es- 
tablished. The circuit remains assigned to that 
call whether any information is being transmitted 
or not, until the call is terminated. 

The equivalent of circuit switching can be pro- 
vided in private networks. For instance, in multi- 
point operation, a primary station authorizes a 
secondary station to transmit, which is the 
equivalent of assigning a circuit. 

Packet switching. There are two main philos- 
ophies being debated in packet switching net- 
works. One is datagram service, and the other is 
virtual call service. We discussed the concepts 
(but not under these names) in our February 1975 
issue. Davies (Reference 3) and Pouzin (Reference 
1) give good discussions of the concepts. 

In datagram service, long messages or long 
records are divided into two or more packets, 
each no greater than the maximum permissible 
length. Each packet has its own header and trailer 
section, and each is individually routed through 
the network. Two undesirable types of events can 
occur. The several packets of a message may ar- 
rive at the destination out of sequence. Or a 
packet may get into an “endless loop” in a series 
of nodes and never get delivered. Adherents of 
datagram service advocate that the network be 
kept as simple as possible, and leave the cures for 
such troubles largely up to the users. 

In virtual call service, a specified path is set up 
from source to destination at the time the call is 
set up. In general, this might be the preferred 
path between the source and destination nodes. 
However, in the case of line outage, excessive 
noise, or excessive load on a channel, an alternate 
path might be picked. But once that path is se- 
lected, it is retained for all packets involved in 
that call until the call is terminated. So packets 
cannot arrive out of sequence due to routing, nor 
will they get in an endless loop. (Of course, if a 
packet in the middle of a message has a transmis- 
sion error in it, it will have to be retransmitted— 
and will be received out of sequence.) 

As indicated earlier, the X-25 packet network 
access protocol (that Ccrrr will vote on in Sep- 
tember) is based on virtual circuit service. Expec- 
tations are that it will become an international 
standard at that time. | 
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Network control 


Should network control be centralized or dis- 
tributed? It is interesting to note that IBM’s cur- 
rent version of sna has reasonably centralized 
control. The central control resides in vTam (or 
TCAM), and second level control is delegated to 
the network control program in the intermediate 
processors. One advantage of centralized control 
is that there is no need for each node to get proc- 
ess status reports from all adjacent nodes. A dis- 
advantage is that if the central processor goes 
down, the network is down. 

It is also interesting to note, as was pointed out 
to us, that IBM has retained its options on this 
question of control. For instance, the phrase “in 
this implementation” has been used repeatedly in 
SNA documentation. So, if the market starts to fa- 
vor decentralized control, it looks like IBM may © 
be able to change sna in that direction rather 
quickly, we were told. 

Distributed control requires that each node 
know the current status of the adjacent normal 
and alternate links and nodes in the network. 
Each node makes its own routing decisions. These 
routings could be dynamic, preferred, or fixed, 
according to the discipline of the network. 


Error control 


Some people point out that end-to-end error 
control is essential for reliable communications. 
The receiving station must assure itself that it has 
received every packet or block, correctly and in 
sequence. Because of this, say these people, the 
node-to-node error control of some networks is 
redundant and probably is not needed. 

So the question is raised: is node-to-node error 
control necessary, or can the same function be 
performed effectively by an end-to-end method? 

We suspect that the eventual decision will be in 
favor of both node-to-node and end-to-end proto- 
cols. The different links in a data communications 
network are the major sources of error, from what 
we have heard, so it would be best to detect and 
correct errors as close to their source as possible. 
Further, node-to-node error control allows for the 
rapid selection of an alternate path, in case of link 
outage, excessive errors, or link overload condi- 
tions. On the other hand, end-to-end control over- 
sees the delivery of all packets, in their proper 
sequence, at the destination. It can cause the re- 


11 


transmission of a packet if the original transmis- 
sion has been lost for any reason. 


Standardization 


Standards can play a very important role in 
both public and private data networks. For pri- 
vate networks, interface and protocol standards 
would allow users to connect, say, terminals from 
a number of suppliers. For public networks, inter- 
face and protocol standards would allow the tele- 
communication agency networks in the several 
countries to be interconnected. 

Sanders (Reference 3) discusses some of the 
areas in which standards are being considered. 
But he argues that the telecommunication 
agencies should not jump too quickly. For in- 
stance, the X-25 protocol being voted on in Sep- 
tember by Ccirrt is a good starting point, he says, 
but it must be expanded in the future. Further, 
nothing like X-25 probably would have been pro- 
posed as recently as three or four years ago, which 
indicates how quickly the field is changing. 

Some of the issues are just coming into focus. 
While standards are needed, a too hasty adoption 
of standards will probably be regretted later. 
Which is to say that users should not expect to see 
other standards adopted at the speed with which 
X-25 apparently is being adopted. 


Network protocols 


We have mentioned above that Hptc is being 
proposed as an international standard, apccp as a 
U.S. standard, and spuc already shows signs of be- 
coming an ad hoc standard. 

One issue in these alternative protocols deals 
with the delay involved in satellite transmission. 
The delay, from earth to satellite and back, is 
about one-quarter of a second. From the time that 
a first packet or block were transmitted, it would 
be one-quarter second before the addressed re- 
ceiving ground station would get the first packet. 
Assuming that the acknowledgement went back 
via satellite, that would mean another quarter 
second. (Conceivably, acknowledgements might 
be sent by terrestrial circuits to cut the delay.) If 
the transmission rate were 50 kbps and if packets 
were 1000 bits in length maximum, this means 
that about 25 packets could have been trans- 
mitted before the first one was acknowledged. As- 
suming that groups of packets would have to be 
retained at the sending end until each packet in 
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the group has been acknowledged, one can see 
that upwards of 100 packets or even more might 
be “in process” at any one time. 

This is the reason that spic’s limit of seven 
packets before an acknowledgement is required is 
considered too low. Sptuc has a nice, clean block 
structure. It will almost surely be made messier by 
allowing for a larger number of blocks to be trans- 
mitted before an acknowledgement is required. 
But with IBM getting into the satellite commu- 
nications field, we suspect that such a change will 
be made. 


Conclusion 


Private data communications networks will be 
in use for years. Telecommunications agencies 
may desire to replace all private networks with 
public data networks, and they may be devel- 
oping services toward that end—but the private 
networks will take a long time to disappear. 

We do think that users should carefully con- 
sider the public offerings developed by the tele- 
communications agencies. For instance, the 
Telenet, pps, and Datran offerings in the U.S., to 
name just a few (and not comparable ones, at 
that), should be considered. 

In the area of private networks, it seems to us to 
be a matter of the network structure and proto- 
cols advocated by IBM versus the structures and 
protocols offered by others. Of the network struc- 
tures that we have examined, none seem to use 
centralized control to the degree that IBM cur- 
rently does. But migration to IBM’s sna might 
well prove to be more costly than migration to 
other network structures and protocols—one rea- 
son being that spLc is not compatible with pre- 
vious protocols. As far as we can tell, migrating to 
SNA means a complete changeover to sDLC termi- 
nals and network processors. Other network 
structures, on the other hand, seem to accept 
asynchronous protocols, Bsc, as well as spDLC. 
Time will show whether IBM retains this posture. 

Our view is that we generally favor the flex- 
ibility and the expected lower costs of the dis- 
tributed control, distributed intelligence network 
structure. We think it will offer more freedom of 
choice to users. But with IBM pushing the cen- 
tralized control approach, it seems very likely 
that a large number of user organizations will fol- 
low that approach. 
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